This looks great, thanks @rmarren1 !

• Let's add an integration test as well that verifies that the attributes are actually rendered in the application.
  • In the dash-renderer repo, we can add a data-test attribute in this test: https://github.com/plotly/dash-renderer/blob/master/tests/test_render.py#L70
  • In this repo, let's create a new test like test_wildcard_data_attributes. This test would look roughly like:

app = dash.Dash()
app.layout = html.Div([
    html.Div(
        id='data-element',
        **{
            'data-string': 'multiple words',
            'data-number': 512,
            'data-none': None,
            'data-date': datetime.datetime(2012, 1, 10),
            'aria-progress': 5
        }
    )
])

self.startServer(app)

div = self.wait_for_element_by_id('data-element')
self.assertEqual(
    div.get_attribute('innerHTML'),
    (
        '<div id="data-element" '
        'data-string="multiple words" '
        'data-number="512" '
        'data-none=""'
        'data-date="2012-01-10"
        'aria-progress="5"'></div>'
)

• Similarly, let's add an integration test that updates these attributes

I'll take a look at plotly/dash-renderer#51 now

• Edit: Added aria-progress to the test example

I've published a prerelease version at pip install dash==0.22.0rc1

Added some comments in plotly/dash-renderer#51 (comment) that actually apply this repo

plotly/dash-html-components#40
plotly/dash-renderer#52

Test is dependent on changes in plotly/dash-html-components#40

This is awesome, thank you!

I see that to implement this, you're now checking not just for valid attributes but also for attributes that match valid wildcards, i.e. 'data-' and 'aria-'. A question - and I'm totally open to being convinced this is a bad idea - is there a reason to not simply allow any attributes, i.e. just not bother checking them? From my naive point of view that seems more future-proof. Could it be harmful somehow?

Edit: thanks for the explanation @chriddyp !

is there a reason to not simply allow any attributes, i.e. just not bother checking them

Yeah, the main issue is that higher-level React based components (i.e. components that don't just render the HTML components) might not actually end up rendering these attributes.

For example, here is the dcc.Slider component: https://github.com/plotly/dash-core-components/blob/d034e25f6f56423ef2de7e5905328396040cf4d8/src/components/Slider.react.js#L23. It is just a light wrapper around the 3rd party rc-slider component (https://react-component.github.io/slider/examples/slider.html) which might not actually end up rendering data-* attributes in the DOM.

So, if we don't do validation of properties on the component-level, then the end user might think that their data-* attributes are getting rendered in the DOM when they actually aren't. It's up to the component author to make sure that their component will render these attributes.

Re future proof - once the component author ends up supporting them, the end users will be able to upgrade their package to the new version that supports them. If they don't get errors on previous versions, then the end user might not be aware that they are working on a version that doesn't yet support these properties and they won't be aware that they need to upgrade.

Very, very nice @rmarren1 🎉

• I've published a prerelease version of dash-html-components at dash-html-components==0.11.0rc1. Let's update the dev-requirements.txt file with this new version so that we can make sure that circleci passes the tests. After everything is merged and released, we can move it up to the new stable version at 0.11.0.

• Finally, let's update the CHANGELOG.md and version.py file. That way, once tests pass I can merge and release immediately.

This is down by the way" https://unpkg.com/dash-html-components@0.11.0rc1/dash_html_components/bundle.js

@rmarren1 - Thank you! This is really great stuff. I'm 👍 with these changes. Is there anything else that you would like to add? Otherwise, I will merge and release.

I'm good with it, go ahead!

@chriddyp to get it working I needed to do both
pip install dash==0.22.0rc1 and
pip install dash_html_components==0.11.0rc1

I needed dash==0.22.0rc2

I'm using dash==0.22.0rc2 and dash_html_components==0.11.0rc1, but as @rmarren1 points out https://unpkg.com/dash-html-components@0.11.0rc1/dash_html_components/bundle.js appears to be down.

So far as I can tell the fix is to use app.scripts.config.serve_locally=True, but this makes it hard for me to load other external JavaScript files (I am trying to also load Bootstrap). Can I currently get this PR working without serve_locally=True? @chriddyp can you say whether the hosting of https://unpkg.com/dash-html-components@0.11.0rc1/ will go back up in the near future? dash==0.22.0rc2 seems to be fine.

@claresloggett, one workaround for using serve_locally=True while also using your own custom JS scripts is to subclass the Dash instance and add the scripts directly into the HTML head tag. You can see an example of this but used for adding custom CSS scripts here.

Try dash-html-components==0.11.0rc5 dash==0.21.1

@rmarren1 thank you, those versions are working for me! \o/

@ned2 that's good advice thanks, it's a workaround for other issues too. I had seen it, just thought I'd check if I really needed to go down that route. For others' reference there is also an open PR to support more flexible JS and CSS inclusion: #171